The information systems (IS) of an enterprise are often responsible for performing the enterprise's database and business logic functions. Database functions involve the management or usage of the enterprise's records (such as accounting records, sales records, billing records, employee records, etc.). Business logic functions are underlying processes of the enterprise that have been reduced to automated execution (e.g., automatically calculating revenues, automatically scheduling services, etc.). Often, a business logic function depends upon the use of a database function (e.g., an automated billing system that invokes the customer order records of the enterprise). Moreover, database application software is often supplied with its own “business logic” software that enables business logic processes that invoke the core database function to be executed.
In modern day enterprises, a complicated infrastructure of inter-networked computing systems and their corresponding software are typically orchestrated to perform, as a cooperative whole, the database and business logic tasks of the enterprise. An exemplary arrangement is depicted in FIG. 1. FIG. 1 shows a network 101, which may be viewed as an enterprise's internal intranet or the Internet (or some combination thereof), to which an application server platform 102-103 and a Java based platform 104-108 are communicatively coupled. Through the immediately following discussion of each of these various functional elements 102-108 and some of their possible inter-relationships amongst each other, techniques employed by IS personnel in building the IS infrastructure of an enterprise should be better appreciated.
An application server 102 is often used to host a variety of applications (such as application 103). Business logic application software and/or database application software are frequent types of application software that are hosted by an application server 102. Here, “hosting” generally means being responsible for interpreting and/or formatting messages received/sent to network 101 so that the application 103 is properly used by the enterprise. For example, in a basic case where application 103 is a business logic application, the application server 102 responds to a request from the network 101 for application 103 (i.e., a request from some entity that has expressed a need for application 103 through network 101) by properly invoking application 103 in response to the request; and, forwards the result(s) of the application's execution to the requestor.
In other instances the application server 102 may perform additional business logic/database functionality “on top of” basic functionality provided by application 103 (e.g., so as to precisely respond to the request that was received from the network 101). The additional business logic/database functionality may involve the invocation of other application software. In further instances the application server 102 may physically assist in the downloading of executable application software to a requestor. Many application servers are responsible for overseeing a plurality of different application software platforms. Moreover, one or more computing systems may be used to perform the application server 102 function. These same one or more computing systems may also be used (depending on implementation preference) to execute one or more of the hosted applications themselves.
Functional elements 104-108 depict a web server 104 and its corresponding Java based “back-end” functionality 105-108. The term “web server” 104 is largely understood to mean being capable of presenting a web based interface (e.g., through the downloading of web pages scripted in HTML format) over a network 101. Accesses to specific web pages associated with the web based presentation are typically formatted in the HTTP protocol. Often, useful tasks that are dependent on business logic and/or database functions are made accessible through a web based presentation. FIG. 1 suggests such an approach by way of the back end servlet engine 105, database (DB) 106 and Enterprise Java Beans (EJB) 107 applications, and J2EE server 108.
A servlet is a body of software typically geared to perform a specific database and/or business logic function (or at least oversee the execution of a specific database and/or business logic function). A servlet engine 105 is an entity capable of supporting the execution of a plurality of servlets and is the “target” for requests that invoke its constituent servlets. The architecture of FIG. 1 suggests that one or more of the various servlets supported by the servlet engine 105 depend upon separately packaged: 1) database software 106; 2) business logic software implemented with Enterprise Java Beans 107; and, 3) database and/or business logic software made accessible in a Java environment through a J2EE server 108.
The servlet engine 105 can also be used to generate web page matter that is forwarded to a user over the network by the web server 104. “Java Server Pages” (JSPs) are web pages having extended embedded software routines (which are often used for displaying dynamic content on a web page). The notion that the servlet engine 105 is a JSP servlet engine indicates that the servlet engine 105 of FIG. 5 is capable of providing JSP type web pages.
Enterprise Java Beans is a Java based application software development environment that produces software routines having a proficiency at being run in a distributed fashion (i.e., across multiple computing systems). Here, EJB 107 and 108 would be understood to correspond to a collection of programs (e.g., business logic programs) written with EJB. J2EE is a Java software platform for building applications that can be executed in a distributed fashion. EJB is a component of J2EE along with Java Server Pages (JSPs) and a variety of interfaces.
J2EE servers are servers retrofitted with J2EE software and are largely used as “middleware” servers that allow legacy, non Java applications to be made accessible and useable in a Java based environment. For example, the J2EE server associated with EJB 108 may be communicatively coupled to older non Java software that is still used to execute specific database and/or business logic routines. In this case, the J2EE server would be responsible for putting a “Java face” to the legacy software from the perspective of the servlet engine 105 (e.g., by accepting Java commands and interpreting them into an format understandable to a legacy routine).
Note that programs associated with EJB 107 and database (DB) 106 are configured to be accessible through a Java Native Interface (JNI) while programs associated with EJB 108 are configured to be accessible through one or more of the native interfaces associated with J2EE. JNI is a programming interface that may be used for function calls such as the functions/programs implemented in database 106 and EJB 107.
The exemplary IS infrastructure of FIG. 1 also shows an HTTP server 118 communicatively coupled to a J2EE server 119. An HTTP server is a server that can respond to requests from a network authored in the HTTP protocol (which is the primary web page identification protocol—thus, HTTP server 118 can also be viewed as a web server). The HTTP server 118 is communicatively coupled to a J2EE server 119.
Many business logic processes require a number of different software components to be invoked in a specific sequence. For example, an automated billing process might first run a database application to check the customer order records of the enterprise and then run an automated scripting application to create a custom tailored invoice for each order. Many business logic processes invoke a significant number of different software components over the course of their execution.
An issue with enterprise information systems is the ability to continuously monitor the specific software components that are used by a particular business logic process. If a particular software component becomes unavailable (for whatever reason) so as to render a business logic process unworkable, the existence of the “problem” may not be known until after the next attempt to use the process after the component became unavailable. This represents an efficiency loss in cases where the “problem” could have been fixed (or at least routed around) during the time period that elapsed from the moment the component became unavailable to the next attempt to run the process.